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ABSTRACT 


It  has  been  well  over  a  decade  since  the  last  time  the  Naval  Sea  Systems  Command  (NAVSEA)  performed  a  full 
blown  preliminary’  and  contract  ship  design.  During  that  time  period  there  have  been  many  advances  in  the 
underlying  technology’  used  by  design  tools,  and  there  have  also  been  changes  to  the  design  process  as  well.  As  a 
result,  NAVSEA  has  the  responsibility  to  evaluate  tools  and  processes  in  order  to  develop  the  next  generation  early 
stage  ship  design  environment  so  that  we  do  not  continue  to  design  tomorrow ’s  ships  with  yesterday ’s  tools.  This 
paper  discusses  the  role  product  model  technology,  high  performance  computing,  and  early  stage  design  tools  can 
play  in  the  development  of future  naval  vessels.  The  subject  of  design  tools  will  be  explored  from  the  perspective  of 
how  they  improve  the  early  stage  ship  design  process  as  well  as  their  role  in  gaining  insights  and  supporting 
oversight  during  the  detailed  design  and  construction  phases  of  a  ship ’s  lifecycle. 


NOMENCLATURE 

CAD  -  Computer-Aided  Design 

CREATE  -  Computational  Research  and  Engineering 

Acquisition  Tools  and  Environments 

HPC  -  High  Perfonnance  Computers 

ONR-  Office  of  Naval  Research 

FEM  -  Finite  Element  Model 

FEA  -  Finite  Element  Analysis 

IGES  -  Initial  Graphics  Exchange  Specification 

NPDI  -  Navy  Product  Data  Initiative 

STEP  -  Standard  for  the  Exchange  of  Product  data 

(ISO  10303) 

LEAPS  -  Leading  Edge  Architecture  for  Prototyping 
Systems 

ASSET  -  Advanced  Ship  and  Submarine  Evaluation 
Tool 

COTS  -  Commercial  Off-the-Shelf  Software 

INTRODUCTION 

Change  is  a  permanent  fixture  within  the  US 
Naval  Shipbuilding  industry,  to  the  acquisition 
process,  and  within  the  NAVSEA  enterprise.  It  has 
been  several  years  since  an  early  stage  design  has 
been  led  and  completed  by  the  government  (Keane  et 
al.  2009).  Major  changes  have  occurred  in  both  the 
sophistication  of  software  products  available  to  the 
marine  industry  as  well  as  the  available  computing 
power.  Open  architectures  and  the  availability  of 
standards  for  the  definition  of  product  model  data  has 
the  potential  to  improve  the  early  stage  design 
process.  Of  course,  many  issues  arise  when 


establishing  a  design  site,  but  this  paper  only 
examines  issues  of  product  model  technology, 
software,  and  early  stage  design  tools.  But  one  thing 
is  for  sure,  the  early  stage  knowledge  embedded 
within  the  NAVSEA  enterprise  is  retiring.  The 
humans  that  managed,  performed,  and  supported 
early  stage  ship  design  are  all  but  gone.  If  the  next 
generation  of  early  stage  ship  designers  are  not 
deliberately  trained,  mentored,  and  given  the  tools 
they  need  to  design  21st  century  ships  within  the  next 
few  years,  there  is  a  distinct  possibility  there  will  be 
none  of  the  current  generation  left  to  pass  on  the 
trade. 

A  BRIEF  HISTORY 

Up  through  the  1990’s  design  sites  supporting  the 
early  stage  design  of  surface  ships  and  submarines 
were  commonplace  within  NAVSEA  (Ayers  et  al. 
1998).  These  design  sites  could  be  found  within 
NAVSEA  office  spaces,  contractors’  facilities,  and  at 
the  Naval  Ship  R&D  Center  in  Carderock,  MD.  They 
were  staffed  by  a  mixture  of  NAVSEA  and  Warfare 
Center  employees  and  resources  obtained  from  local 
Naval  Architecture  firms.  Depending  on  the 
acquisition  strategy,  some  of  the  design  teams  would 
include  the  shipyards  that  may  be  bidding  on  the 
detailed  design  and  construction.  During  these 
bygone  days,  NAVSEA  was  deeply  involved  in  the 
use  and  customization  of  commercial  CAD  systems, 
the  continuous  evaluation  of  commercial  Naval 
Architecture  tools,  and  where  necessary,  the 
development  of  specific  design  tools.  NAVSEA,  as 
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well  as  any  major  enterprise  involved  in  the  design  of 
their  products  struggled  with  the  balance  between  the 
use  of  commercially  available  software  and  the  in- 
house  development  of  software.  This  problem  was 
compounded  by  the  relatively  small  size  of  the 
marine  sector  coupled  with  trying  to  define  the 
Navy's  core  competencies  in  software  development. 
During  the  acquisition  reform  of  the  mid-nineties, 
many  of  the  responsibilities  traditionally  assigned  to 
the  NAVSEA  engineering  directorate  were  transferred 
to  the  industrial  sector.  One  critical  result  was  less 
Navy  engineering  and  more  Navy  engineering 
oversight.  The  old  adage  goes  "you  forget  what  you 
hear,  you  remember  what  you  see,  and  you  know 
what  you  do."  Because  NAVSEA  is  not  doing  ship 
design,  it  is  missing  an  opportunity  to  pass  on 
corporate  engineering  knowledge  to  the  next 
generation  of  ship  designers,  ship  design  managers, 
and  design  integration  managers.  The  time  is  ripe  for 
NAVSEA  to  rebuild  its  early  stage  design 
competency.  With  improvements  in  infonnation 
technology,  we  are  afforded  an  opportunity  to 
integrate  cutting  edge  information  technologies  with 
established  analysis  tools  and  the  knowledge  of  an 
aging  workforce. 

THE  CASE  FOR  TOOL  DEVELOPMENT 

Ships  are  large  and  complex  products  and  have  a 
long  development  cycle.  It  is  widely  recognized 
throughout  the  engineering  world  that  decisions  made 
during  the  conceptual  design  phase  have  the  largest 
impacts  on  cost,  performance,  and  schedule.  Many 
of  the  critical  requirements  levied  on  a  warship 
require  complex  analysis  to  verify  that  they  are  met 
(such  as  hull  fatigue  life,  vulnerability/shock 
performance,  signatures,  and  topside 
sensing/communication  perfonnance).  These 
complex  analyses  require  a  high  level  of  design 
definition,  which  is  typically  not  available  until  the 
detailed  design  and  construction  phase.  In  the 
current  design  paradigm,  analysis  results  that  verify  if 
a  ship  design  meets  its  requirements  come  after  their 
opportunity  to  influence  the  design.  Because  of  the 
limited  amount  of  tool  integration,  and  a  manual  ship 
design  definition  process,  the  Navy  enterprise  usually 
driven  to  select  one  design  alternative  early  in  the 
design  process.  Much  of  the  rest  of  the  design  effort 
is  spent  detailing  and  reworking  this  single 


alternative  to  meet  the  requirements  and  cost  goals. 

The  vision  for  Navy  design  tools  is  to  move  to  a 
automated  high-end  toolset  that  integrates  many 
infonnation  dense  design  definition  tools  with  high 
fidelity  physics-based  analysis  tools.  This  toolset 
will  be  able  explore  many  ship  design  alternatives  to 
populate  a  feasible  design  space.  This  design  space 
will  be  used  to  perform  real  time  cost-benefit  trades 
on  ship  requirements  during  the  requirements 
definition  process.  A  system  such  as  this  could  be 
used  to  explore  the  design  space  to  ensure  that  the 
correct  design  is  selected  before  signing  a  contract  to 
build  a  ship. 

Direction  on  this  was  given  to  NAVSEA  in 
February  of  2008  in  a  memo  from  Admiral  Sullivan, 
who  was  then  COMNAVSEA,  which  outlines  types 
of  tools  and  tool  developments  needed.  The  memo 
sates  that, 

Accomplishing  these  ambitious  goals  will  be  a  challenge, 
but  is  essential  for  crafting  affordable,  executable  ship 
programs  in  an  increasingly  complex  national  security 
environment.  Previous  Navy  design  tool  investment  has 
resulted  in  the  Advanced  Ship  and  Submarine  Evaluation 
Tool  (ASSET)  for  total  ship  synthesis,  and  the  Leading 
Edge  Architecture  for  Prototyping  Systems  (LEAPS)  for 
integrating  a  wide  range  of  analysis  tools  in  a  common 
data  environment.  Future  tool  development  should  build 
upon  these  foundations,  adding  capability  to  meet  the 
goals  outlined  in  this  memorandum.  [Ser  05D/047,  4  Feb 
2008] 

ASSET  is  software  that  has  been  built  and 
maintained  by  the  Navy  at  NSWC  Carderock  for  over 
25  years,  and  it  is  currently  the  principal  tool  used  in 
earliest  stages  of  ship  design.  ASSET  is  unique  in  that 
it  combines  ship  design  disciplines  into  one 
synthesized  whole-ship  model  that  represents  a 
balanced  design.  A  major  issue  is  that  ASSET  does 
not  produce  the  level  of  design  definition  required  for 
many  of  the  higher-level  analyses  required  in  the  later 
stages  of  ship  design.  When  a  design  progresses 
beyond  concept  design,  where  a  more  detailed 
analysis  is  needed,  the  design  integration  provided 
between  disciplines  by  ASSET  is  lost.  Existing 
analysis  tools  typically  require  their  own  custom 
format  of  input  data.  Up  to  90%  of  the  time  spent  on 
these  analyses  is  spent  preparing  the  input,  which 
often  means  manually  recreating  design  data  that  was 
already  created  in  another  tool.  This  data  recreation 
accounts  for  most  of  the  time,  cost,  and  error 
associated  with  analysis. 
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The  effort  to  solve  this  time-delay  and 
configuration  control  issue  between  high-end  tools  is 
LEAPS.  LEAPS  is  also  developed  and  maintained  by 
the  Navy  at  NSWC  Carderock,  and  has  been  a  15- 
year  effort.  At  its  base  LEAPS  is  a  digital 
representation  of  the  ship  designed  to  be  expansible 
to  include  all  information  necessary  to  perform  any 
relevant  analysis  and  store  the  results  of  those 
analyses  for  use  by  other  analyses.  It  is  the  hub, 
while  detailed  discipline-specific  tools  represent  the 
spokes  in  a  ship  design  cycle.  Careful  though  and 
planning  is  required  to  bring  a  LEAPS  based  design 
and  analysis  for  a  new  ship  to  fruition.  What  design 
and  analysis  activities  are  performed  at  each  phase  of 
the  design  should  be  planned  carefully  to  ensure  that 
the  information  is  created  before  it  is  required.  The 
way  that  design  tools  interact  is  directly  related  to  the 
way  we  design  ships,  and  the  way  people  think  about 
design.  The  process  that  forms  the  foundation  of 
ASSET  reflects  the  roles  and  responsibilities  of 
NAVSEA  at  the  time  ASSET  was  created.  Efforts  are 
currently  underway  to  map  the  entire  ship  design 
process  so  that  gaps  in  the  ship  design  toolset  can  be 
identified.  This  map  will  also  allow  NAVSEA  to 
engineer  and  streamline  the  ship  design  process.  This 
effort  is  tied  to  the  NAVSEA  Tools  Roadmap 
development  and  semi-annual  workshops  sponsored 
by  NAVSEA,  ONR,  and  the  CREATE  program,  but 
this  is  a  subject  for  another  paper. 

CREATE  (Computational  Research  and 
Engineering  Acquisition  Tools  and  Environments)  is 
a  DoD  program  that  is  focused  on  tackling  many  of 
these  challenges.  The  program  is  run  out  of  the  DoD 
High  Performance  Computers  Modernization  Office 
(HPCMO).  CREATE-SHIPS  (a  portion  of  the  overall 
CREATE  program)  is  budgeted  to  spend  several 
million  dollars  from  HPCMO  over  the  next  few 
years,  and  focuses  on  leveraging  the  modern 
increases  in  computational  power  to  develop  the 
high-end  toolset  and  enable  this  process  of  rapidly 
designing  and  analyzing  large  number  if  ship  designs. 
CREATE-SHIPS  is  a  partnership  between  NAVSEA, 
ONR,  HPCMO,  and  PEO  SHIPS.  Another  positive 
step  at  NAVSEA  was  the  establishment  of  the 
Technical  Warrant  Holder  position  for  Ship  Design 
Tools  in  October  of  2008  as  a  step  towards  raising  the 
importance  of  ship  design  tools  in  the  overall  design 
and  certification  process.  In  December  2009,  this 


position  was  moved  to  the  NAVSEA  05  Chief 
Technology  Office  as  the  Tools  Program  Manager, 
further  elevating  the  importance  of  tool  development 
to  the  NAVEA  enterprise. 

In  addition  to  the  issue  of  configuration  between 
disciplines,  many  aspects  of  ship  design  do  not  have 
sufficient  tools  and  models  in  existence,  and 
increasingly  rely  on  engineering  judgment  and  large 
factors  of  safety.  For  instance,  we  are  often  looking  at 
new  and  innovative  ways  to  estimate  a  ship’s 
manning  requirements  or  costs  at  an  early  stage.  But 
developing  and  improving  the  individual  high-end 
tools  themselves  is  not  as  simple  as  implementing  a 
theory  into  a  computer  algorithm.  Tools  need  to  be 
verified  and  validated;  problems  must  be  easy  to  set 
up  and  run;  geometry  and  mesh  generation  must  be 
easy  and  quick;  tools  must  be  built  to  run  effectively 
and  efficiently  on  highly  complex  massively  parallel 
computers;  and,  results  must  be  timely.  Many  of  the 
tools  we  use  are  highly  specialized,  and  not  used 
beyond  the  narrow  realm  of  Naval  ship  design.  The 
results  of  these  complex  analyses  must  be  visualized 
and  packaged  in  a  way  that  they  are  easy  to 
understand  by  both  the  design  engineers  and  program 
managers  such  that  they  can  be  the  basis  of  a  smart, 
timely  decision  making  process. 

A  CREATE  effort  of  note  is  the  development  of 
the  Integrated  Hydrodynamics  Design  Environment 
(IHDE).  For  ship  hydrodynamics  a  large  set  of 
specialized  commercial,  government,  and  even 
university  built  research  tools  and  models  is  used  for 
all  aspects  of  ship  hydrodynamics  such  as  resistance, 
seakeeping,  stability,  and  fluid-structure  interactions. 
Most  of  these  tools  are  highly  specialized  and  only 
experts  can  run  them.  The  IHDE,  now  in  its  second 
year  of  development,  seeks  to  provide  a  unified  easy- 
to-use  system  that  gives  a  ship  designer  the  ability  to 
interface  more  directly  with  these  tools.  It  also  has 
the  ability  to  create  input  files  from  ship  design  data 
available  in  the  LEAPS  representation  of  the  ship 

Figure  1  The  Integrated  Hullform  Design  Environment  ties  together 
several  hydrodynamics  tools 

automatically,  and  to  store  the  results  of  the  analysis 
back  into  LEAPS. 

Another  software  development  worthy  of 
discussion  here  is  Intelligent  Ship  Arrangements 
(ISA),  which  is  a  tool  in  its  infant  stages  developed  as 
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a  research  project  at  the  University  of  Michigan  and 
not  yet  transitioned  to  Navy  use.  As  mentioned 
earlier,  many  cases  an  analysis  cannot  be  performed 
due  to  a  lack  of  the  design  definition  needed.  A  major 
hurdle  is  that  ship  arrangements — the  way  that 
compartments  and  machinery  are  laid  out  relative  to 
one  another — is  an  intensive  manual  process  and 
often  considered  more  art  than  science  because  of  the 
unlimited  number  of  viable  solutions.  This  tool  looks 
at  the  arrangements  within  a  ship's  hull  as  an 
industrial  engineering  problem,  a  hybrid  of  efficiently 
packing  a  box  and  laying  out  circuitry  on  a 
microchip,  and  arranges  the  ship  according  to 
constraints  and  rules  set  by  the  users  ahead  of  time. 
When  used  in  a  systematic  and  stochastic  way,  and 
when  integrated  using  LEAPS,  having  this  type  of 
design  information  early  in  the  design  process  can 
feed  into  analyses  such  as  manning,  vulnerability, 
producibility,  and  a  number  of  other  “ilities”  in  time 
to  influence  major  ship  design  decisions. 

Ultimately,  our  goal  is  to  shrink  the  time  required 
to  generate  a  sufficient  amount  of  information  to 
make  informed  design  decisions  early  in  the  ship 
design  process  before  the  requirements  are  set  and 
cost  of  the  ship  is  locked  in.  By  considering  an 
integrated  computational  ship  model  as  a  “virtual 
prototype,”  several  design  iterations  are  possible  in  a 
far  shorter  amount  of  time  than  a  single  design-build- 
test  cycle  of  a  traditional  prototype. 

One  commercial  example  illustrates  what  we  can 
now  achieve  with  this  paradigm.  In  the  early  1990s, 
Goodyear  Tire  faced  intense  international 
competition.  Its  rivals  had  more  engineering  design 
resources,  testing  capacity,  and  lower  production 
costs — Goodyear  was  rapidly  falling  behind.  To 
respond  and  develop  a  competitive  advantage,  it 
replaced  the  traditional  engineering  process  (design, 
build,  test,  and  repeat)  that  had  served  it  well  for 
more  than  100  years  with  physics-based 
computational  engineering  tools  to  design,  mesh,  and 
analyze  new  products.  Engineers  built  and  tested  just 
the  final,  optimized  designs,  thereby  reducing 
Goodyear’s  time  to  market  from  three  years  to  less 
than  a  year.  The  company  started  producing  several 
new  designs  a  year  instead  of  one  or  two  every  few 
years.  Goodyear  is  now  the  largest  US  tire 
manufacturer  and  is  competitive  in  the  world  market. 
Whirlpool,  Proctor  and  Gamble,  Boeing,  Ping  Golf, 


and  Pratt  and  Whitney,  to  name  a  few,  have  also 
adopted  this  new  paradigm  with  similar  success. 

In  addition,  Systems  Engineering  tools  and 
methodologies  such  as  Set-Based  Design  along  with 
techniques  for  Design  of  Experiments  and  Multi- 
Disciplinary  Optimization  can  help  integrate 
seemingly  disparate  types  of  analysis.  Stochastic 
analysis,  now  available  to  us  through  automation  and 
high-speed  computing,  will  not  only  allow  us  to 
better  capture  uncertainty  into  the  design  process,  but 
it  allows  several  single  aspects  of  a  ship  design  to  be 
explored  comprehensively  on  their  own  before 
comparing  them  to  ensure  convergence  and 
feasibility  of  the  ship  design  as  a  whole.  In  addition 
to  linking  ship  structures,  hydrodynamics,  and 
susceptibility  models  for  instance,  the  front  end  can 
link  to  force  models  and  the  back  end  can  link  with 
cost  and  affordability  models  to  provide  a  full  picture 
to  decision  makers  so  that  timely  decisions  can  be 
made  with  confidence. 

AN  INTRODUCTION  TO  EARLY  STAGE  SHIP 
DESIGN 

Decisions  made  early  on  in  the  ship  design  process 
have  large  impacts  on  ship  functionality  that  isn’t 
quantified  until  the  design  is  mature.  Often  these 
impacts  are  only  vaguely  understood  at  the  outset  of 
the  design  cycle,  and  by  the  time  that  the  impacts  are 
fully  understood  it  is  too  late  to  make  significant 
changes.  An  example  of  this  could  be  the 
vulnerability  of  the  ship:  in  order  to  asses  a  ship’s 
vulnerability,  a  detailed  layout  of  compartments  and 
distributed  systems  is  needed,  but  early  on  in  the  ship 
design,  when  sizing  decisions  are  made,  detailed 
layouts  are  not  available  and  a  ship  designer  has  little 
more  than  rules-of-thumb  to  base  these  crucial 
decisions  upon.  With  High  Performance  Computing 
(HPC)  as  an  enabler,  the  vision  is  to  explore  all 
downstream  implications  of  decisions  made  during 
the  initial  concept  development  and  apply  that 
knowledge  as  early  on  in  the  design  process  as 
possible.  In  the  vulnerability  example  used  above,  for 
instance,  an  automated  tool  (such  as  ISA  mentioned 
earlier)  could  rapidly  produce  a  full  range  of  feasible 
ship  arrangements  from  a  basic  shell  of  a  ship,  and 
then  a  vulnerability  assessment  could  be  performed 
on  each  of  these  many  design  variations  and  the 
resultant  range  of  achievable  levels  of  vulnerability 
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can  be  fed  back  to  the  designer — with  all  of  the  high¬ 
speed  computation  happening  behind  the  scenes. 
Thus,  the  designer  is  instantly  aware  of  the 
vulnerability  implications  of  the  sizing  and 
arrangement  of  the  ship. 

Design  Spiral  versus  Set-Based  Design 

Naval  Ship  Design  involves  complex  interactions 
between  many  disciplines,  and  reconciling  the  needs 
of  one  system  against  others  becomes  a  delicate 
balancing  act.  The  convergence  of  various  discipline- 
specific  ship  models  into  a  single  coherent  design  is  a 
process  that  NAVSEA  has  termed  “Ship  Synthesis,” 
and  is  currently  chiefly  perfonned  using  the  Navy’s 
in-house  tool  ASSET.  ASSET  is  made  up  of 
discipline  specific  modules  (i.e.  hull  geometry,  gross 
arrangement,  hull  structural  design,  resistance  and 
propulsion,  power  plant  sizing,  weight  estimation, 
and  area/volume  sufficiency  analysis).  ASSET 
performs  synthesis  between  these  modules  using  a 
design  spiral  approach.  This  means  that  disciplines 
are  analyzed  one  at  a  time  before  moving  to  the  next 
one,  and  multiple  iterations  are  performed  through 
the  spiral  process  in  order  to  converge  into  a  single 
solution.  Each  loop  is  a  serial  process  that  must  be 
done  in  order,  and  control  of  each  design  variable 
must  be  carefully  managed.  The  modules  in  ASSET 
are  highly  coupled  so  that  the  dynamic  process  of 
synthesis  is  stable  and  converges  on  a  solution. 

In  a  Set-Based  Design  approach,  which  has  been 
identified  as  a  preferred  approach  for  the 
development  of  future  U.S.  Naval  design  efforts, 
discipline-specific  designs  are  done  in  parallel  across 
a  broad  design  space.  This  process  is  designed  to 
improve  the  flexibility  of  the  design  by  delaying  key 
decisions  until  the  design  space  is  fully  understood, 
but  the  parallel  nature  of  the  approach  also  makes  it 
an  ideal  fit  for  HPC  application.  Currently,  set-based 
design,  as  practiced  in  the  Navy’s  Ship-to-Shore 
Connector  program,  relies  on  engineering  interaction 
and  judgment  for  creating  the  set  information  from 
each  discipline  and  integrating  the  results  from 
multiple  disciplines  in  order  to  find  a  set  of  possible 
solutions.  But  techniques  known  as  Multi- 
Disciplinary  Optimization  (MDO)  offer  the 
infrastructure  for  integrating  the  set  based  design 
theory  into  Navy  ship  design  tools  in  a 


mathematically  rigorous  and  automated  manner. 
Applications  of  MDO  techniques  to  ship  synthesis 
are  ready  to  be  tested  and  implemented  and  are 
moving  forward.  Due  to  the  highly  coupled, 
multivariate  nature  of  the  ship  design  problem,  MDO 
will  be  challenging,  but  holds  great  promise  as  an 
integrating  agent. 

The  Navy  Business  Model 

It  is  important  at  this  point  in  the  discussion  to 
recognize  the  business  environment  in  which  the 
Navy  designs  ships.  Although  the  details  of  ship 
procurement  seem  to  change  weekly,  the  basic  initial 
design  process  remains  generally  the  same.  In  the 
initial  phase  a  large  design  space  of  many  options  is 
explored  to  a  low  level  of  fidelity,  and  with  each 
successive  phase  of  the  design,  guidance  is  given  to 
the  designer  by  a  decision  maker  and  the  fidelity  of 
the  design  is  increased  along  with  a  decrease  in  the 
range  of  options  available.  This  process  is  depicted 
graphically  in  Figure  2.  As  the  design  space  starts  to 
become  defined,  higher  order  models  can  be 


Figure  2  As  the  fidelity  of  the  design  increases,  the  design  space 
under  consideration  gets  smaller. 

substituted  into  the  Ship  Synthesis  process.  HPC 
tools,  such  as  the  ones  being  developed  under  the 
CREATE  Hydro  and  Shock  projects,  can  become 
appropriate  higher  order  models  when  the  design 
space  becomes  sufficiently  defined,  and  as  these  tools 
become  faster  and  more  accessible,  they  can  be  used 
in  earlier  phases  of  the  design. 

HPC  tools  for  other  disciplines,  beyond  just 
hydrodynamics  and  shock,  need  development  as  well, 
and  an  analysis  of  which  disciplines  hold  promising 
theories  that  are  applicable  to  solution  by  HPC  (i.e. 
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large  amounts  of  numerical  calculations)  should  be 
done,  and  investments  should  be  made  in  those  areas. 
An  example  of  this  is  the  Intelligent  Ship 
Arrangement  technique  under  development  at  the 
University  of  Michigan,  which  was  mentioned  earlier 
in  the  paper. 

ASSET  Evolution 

The  vision  for  future  ASSET  is  to  expand  its  ship 
definition  and  analysis  capability.  Ship  definition 
capability  will  be  greatly  enhanced  through  the  use  of 
a  3D  NURBS  based  geometry 
definition/manipulation,  arrangements,  and 
component  placement  capability.  This  capabiltiy  will 
come  through  the  conversion  of  the  ASSET  data 
model  into  a  LEAPS  data  model.  This  will  allow  the 
rapid  turnaround  between  this  design  tool  and  higher 
fidelity  physics  models  that  require  complicated 
mesh-able  geometry  and  detailed  ship  design 
information.  Arrangement  details  such  as  topside 
design  and  distributed  system  routing/architecture 
will  make  it  possible  to  assess  topside  effectiveness 
and  vulnerability  during  concept  design.  Pre-defined 
components  will  be  stored  in  a  LEAPS  database  and 
used  in  the  ASSET  model.  ASSET  will  be  run  in  a 
batch  mode  to  create  hundreds  or  thousands  of 
feasible  design  variants  that  will  be  analyzed  to 
determine  their  effectiveness. 

Using  Behavior  Models 

In  order  to  use  higher  order  models  within  a  Ship 
Synthesis  process  and  get  results  in  a  timely  manner, 
the  results  of  many  runs  of  the  higher  order  models 
must  be  abstracted  into  a  “Behavior  Model.”  These 
are  sometimes  also  referred  to  as  “Surrogate 
Models,”  or  “Response  Surfaces.”  The  idea  behind  a 
Behavior  Model  is  that  from  many  discrete  points  in 
a  design  space,  a  continuous  function  can  be  closely 
fit,  and  that  function  can  be  queried  instantaneously 
rather  than  re-running  the  computationally  intensive 
higher  order  model.  In  this  way,  the  Ship  Synthesis 
process  using  full  physics  models  can  be  done  in  real 
time.  The  design  space  can  be  explored  or  an 
optimization  performed  in  a  reasonable  timeframe  by 
a  single  user.  Done  in  this  manner,  several  higher 
order  models  in  several  disciplines  can  be  run  in  a 
highly  parallel  way  over  a  broad  range  of  design 


space  prior  to  the  Ship  Synthesis  process.  Figure  2 
illustrates  the  process  of  defining  a  feasible  design 
space  in  an  initial  phase  of  the  design.  Later  an  aspect 
of  the  design  is  explored  in  more  detail  using  HPC 
tools,  and  a  Behavior  Model  is  developed  from  the 
results.  This  Behavior  model  can  then  be 
incorporated  back  into  a  Ship  Synthesis  in  the  next 
design  phase.  A  similar  approach  to  this  was  taken 
during  the  ONR  HSSL  effort,  where  seakeeping  and 
resistance  Behavior  Models  were  developed  based  on 
parametric  hullform  changes,  and  these  Behavior 
Models  were  used  as  part  of  Ship  Synthesis.  Using 
HPC,  this  effort  was  able  to  build  these  Behavior 
Models  in  two  to  three  days  rather  than  the  5,000  plus 
hours  of  computing  time  that  it  would  have  taken 
otherwise. 


Figure  3.  Higher  order  models  used  in  successive  design 
phases  in  the  Ship  Synthesis  process  can  be  Behavior 
Models  created  from  HPC  results. 

Several  mathematical  models  exist  for  developing 
Behavior  Models,  including  polynomial  splines, 
neural  networks,  and  Kriging,  and  some  are  more 
appropriate  than  others  for  certain  applications.  These 
methods  need  to  be  characterized  and  developed  into 
software  that  works  within  the  Navy's  ship  design 
infrastructure  and  can  be  used  in  a  parallel  computing 
environment. 

Leading  Edge  Architecture  for  Prototyping  for 
Systems 

LEAPS  is  a  Navy  developed  environment  for 
storing  information  about  ship  designs.  It  functions  as 
a  database  that  is  capable  of  storing  multiple  ship 
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concepts,  including  detailed  geometry  information, 
numerical  design  infonnation,  system  attribution,  and 
behavior  objects.  A  further  discussion  of  LEAPS  as  a 
product  model  is  discussed  later  in  this  paper. 

Currently,  CREATE  Ships  has  funded  the 
University  of  Michigan  to  update  the  database 
structure  of  LEAPS  to  enable  queries  to  be  made  in 
parallel,  enabling  the  use  of  LEAPS  in  a  highly 
parallel  computing  job  such  as  running  many  designs 
through  multiple  scenarios  in  a  seakeeping  analysis. 

The  DOD  CREATE  program,  along  with 
NAVSEA,  is  also  currently  developing  the  capability 
within  LEAPS  to  parametrically  distort  a  parent 
hullform  so  that  a  large  design  space  can  be  created 
and  run  through  HPC  analysis  tools  such  as  those 
accessible  from  the  Integrated  Hydrodynamics 
Design  Environment.  This  hullform  manipulation 
toolkit  is  also  an  enabler  for  doing  set-based  design 
of  the  hullform  in  parallel  with  other  aspects  of  the 
ship. 

Planned  Tool  Improvements  for  the  Concept 
Design  Phase 

In  the  concept  design  phase,  the  ship  design 
organization  should  explore  large  sets  of  potential 
design  alternatives  using  design  space  exploration 
and  visualization  methods.  To  use  this  method,  an 
automated  toolset  is  needed  that  can  rapidly  populate 
a  design  space  with  perfonnance,  cost,  and  risk  data. 
There  are  several  areas  of  improvement  that  have 
been  identified  to  fill  in  a  complete  toolset  for 
concept  design.  As  we  continue  to  identify  and 
prioritize  these,  actions  should  be  taken  to  improve 
those  areas. 

During  this  phase  the  level  of  detail  may  be 
relatively  low,  but  the  design  is  extremely  dynamic. 
The  process  is  dominated  by  synthesis  tools  and  low 
level  analysis.  The  emphasis  during  this  phase  is  to 
identify  solutions  that  are  feasible.  The  majority  of 
the  design  effort  is  performed  using  ASSET  and  a 
host  of  analysis  tools  that  will  quickly  at  a  low  level 
of  detail  identify  windows  of  feasibility  considering 
many  variables  including;  cost,  weight,  arrangeable 
space,  powering,  and  many  others  (Doerry  2009). 
The  plan  is  to  improve  ASSET,  build/integrate 
additional  design  and  analysis  tools,  and  provide  a 
tighter  integration  with  LEAPS  (NAVSEA  05D 


2008). 

There  are  several  products  that  are  planned.  These 
include  Force  Architecture  Assessment  and 
Operational  Effectiveness  Analysis.  Plans  are  to 
integrate  all  of  the  design  information  into  the 
LEAPS  schema. 

Preliminary/Contract  Design 

In  the  preliminary  design  phase,  ship  designers 
will  continue  to  explore  sets  of  potential  design 
alternatives,  but  now  to  a  higher  level  of  fidelity  and 
a  less  broad  range.  Design  integration  of  a  set  based 
preliminary  design  will  be  challenging.  Design  space 
visualization  is  required  to  understand  the  whole  ship 
impact  of  design  decisions.  As  mentioned  above, 
ASSET  will  be  further  integrated  with  LEAPS,  so 
that  higher  fidelity  preliminary  design  infonnation 
can  be  replace  the  lower  fidelity  concept  design 
infonnation  initially  generated  by  the  program.  The 
program  will  also  allow  multiple  users  to  work  in 
parallel  on  different  parts  of  the  ship  to  speed  the 
design  definition  process.  In  this  phase  of  the  design, 
the  synthesis  process  will  be  much  more  focused  on 
individual  aspects  of  the  design,  which  will  be 
worked  in  great  detail,  whereas  larger  scale  changes 
will  be  less  common. 

The  Graphical  User  Interface  (GUI)  for  ASSET 
will  need  to  be  much  improved.  ASSET  of  the  future 
will  feature  a  GUI  that  guides  the  user  through  the 
design  process.  The  new  GUI  will  allow  the  user  to 
have  point-and-click  subdivision  definition  and 
interactive  arrangement  capability  that  will  allow  the 
user  to  see  and  manipulate  the  design  in  three 
dimensions.  This  GUI  will  allow  the  user  to  place 
machinery  components,  place  topside  equipment,  and 
define  distributed  system  runs  using  a  three 
dimensional  representation  of  the  ship.  The  ability  to 
place  topside  equipment  on  the  three  dimensional 
product  model  of  the  ship  will  allow  ASSET  to 
perfonn  topside  design.  ASSET  will  also  be  able  to 
interface  with  physics  based  topside  analysis  tools 
using  a  LEAPS  interface.  A  topside  design  utility 
will  feature  a  complete  library  of  existing  topside 
sensors,  where  pertinent  design  infonnation  has  been 
pre-populated.  The  user  will  be  able  to  define  the 
necessary  distributed  system  runs  that  will  allow  the 
ASSET  model  to  be  used  to  populate  the  data 
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necessary  for  vulnerability  analysis.  This  will  enable 
vulnerability  analysis  earlier  in  the  design  process. 
The  ASSET  GUI  will  allow  the  user  to  do  general 
arrangements  of  the  ship  design,  enabling  the 
functional  allocation  of  space  to  be  made  in  the  ship 
design  process.  This  capability  will  allow  the  user  to 
consider  modularity  during  the  design,  and  quantify 
how  the  placement  of  modules  affects  the  general 
arrangement.  Automated  internal  and  topside 
arrangement  capability  is  currently  under 
development  in  the  Intelligent  Ship  Arrangement 
tool. 

A  mission  system  component  catalog  will  be 
developed.  This  data  will  be  captured  in  a  LEAPS 
database  of  group  400  (sensors  and  communications 
equipment)  and  700  (weapons)  systems  that  are 
found  in  existing  ships,  or  being  considered  for  future 
ships.  The  pedigree  of  the  information  will  be  stored 
in  the  LEAPS  database  along  with  each  component  to 
indicate  if  the  system  attributes  are  “as  built”  or  were 
captured  at  some  “non-final”  stage.  This  database 
will  be  accessible  and  used  as  a  primary  payload 
database  for  ASSET.  The  component  catalog  will 
contain  the  component  attributes  necessary  to 
determine  the  ship  impact  and  perform  the  necessary 
analysis.  The  information  will  contain  weight, 
area/volume,  power,  cooling,  component  specific 
location  restrictions,  and  the  specifics  required  for 
analysis  (such  as  electromagnetic  emissions).  This 
data  will  be  mined  from  certified  data  sources,  and 
will  therefore  become  the  authoritative  data  set  that 
can  be  referenced  and  used  for  future  design  studies. 
A  process  will  be  put  into  place  to  guide  a  user 
through  the  proper  population  of  a  mission  system 
into  ASSET.  A  mission  system  configuration  utility 
will  be  added  to  ASSET  to  guide  the  user  through  a 
selection  and  placement  process. 

Functional  Arrangement 

During  the  preliminary  design  a  greater  emphasis 
is  placed  on  optimizing  the  general  arrangement  by 
considering  the  location  of  equipment,  outfitting,  and 
routing  lanes.  The  first  iteration  of  the  preliminary 
design  LEAPS  model  is  a  product  of  the  ASSET 
synthesis  developed  during  the  concept  phase.  The 
current  process  is  heavily  dependant  upon 
commercial  CAD  tools  where  the  geometry 
manipulation  capabilities  of  the  CAD  system  can  be 


used  to  detail  the  arrangement.  This  process  is 
heavily  dependent  on  the  existence  of  a  reliable  and 
efficient  data  exchange  capability.  It  is  envisioned 
that  a  limited  portion  of  the  arrangement  function  will 
be  performed  in  an  automated  manner  using  the 
Intelligent  Ship  Arrangements  (ISA)  tool. 

This  evolving  functional  arrangement  continues  to 
be  closely  coupled  to  the  hullform,  many  times 
requiring  analyses  typically  associated  with  the 
concept  phase.  During  this  phase  the  level  of  detail  is 
increasing,  and  more  importantly  the  ship  design  is 
maturing.  This  enables  more  types  of  analysis  to  be 
perfonned  in  order  to  validate  that  the  design  meets 
the  requirements.  These  types  of  analysis  include; 
stability,  vulnerability,  survivability,  shock,  and  a 
more  in-depth  evaluation  of  structural  strength  and 
fatigue  perfonnance,  and  hydrodynamic  performance. 

COTS  VS.  ORGANIC 

This  question  has  been  haunting  NAVSEA  forever. 
During  the  mid  1980’s  it  became  especially 
contentious  in  an  era  nostalgically  referred  to  as  “the 
CAD  wars.”  One  faction  was  adamant  that  the  only 
way  NAVSEA  could  obtain  design  tools,  including 
drafting  tools  was  to  have  them  developed  in-house. 
The  other  faction  was  equally  as  adamant  that  the 
CAD  industry  could  provide  all  tools  necessary  to 
support  early  stage  ship  design.  We  have  since 
learned  that  a  combination  of  COTS  and  organic 
design  tools  are  necessary;  although,  we  are  not 
always  properly  perfonning  this  trade-off.  We  have 
also  learned  that  most  of  the  time  COTS  tools  require 
some  amount  of  customization  to  be  useful  for  Navy 
design  applications.  The  reality  is  that  even  the 
organic  tools  require  a  formal  set  of  processes  to 
ensure  that  they  are  used  correctly.  If  a  COTS 
package  has  the  capability  required,  can  reasonably 
be  integrated  into  the  design  process,  and  proves  to 
be  the  most  cost  effective  solution,  it  should  be  used. 
NAVSEA  has  limited  resources  to  develop  and 
maintain  in-house  software,  and  it  should  be  used  to 
develop  core  Navy  capabilities  that  commercial 
industry  has  no  incentive  to  develop  on  it's  own. 

Integrating  Design  Tools 

The  Navy's  plan  is  to  implement  LEAPS  as  the 
method  for  integrating  the  design  information,  and  in 
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many  cases,  interacting  design  tools..  There  are  two 
options  to  using  LEAPS  as  the  design  tools 
integrator.  Option  one  is  to  modify  design  tools  to 
directly  use  the  LEAPS  repository  as  their  native 
database  fonnat.  Option  two  is  to  create  a  translator 
that  will  extract  that  information  required  for 
performing  the  analysis  and  upon  completion  of  the 
analysis  will  write  the  results  back  to  the  LEAPS 
repository.  The  first  option  is  best  for  new  tool 
development,  while  the  second  option  may  be  more 
palatable  for  existing  tools. 

LEAPS  AS  A  SOFTWARE  ENVIRONMENT 

LEAPS  is  a  very  powerful  software  environment 
that  includes  a  CAD  and  math  engine,  and  several 
useful  toolkits.  Both  the  LEAPS  software  and  all  of 
the  supporting  documentation  is  now  approved  for 
unlimited  distribution,  and  is  available  to  software 
developers  for  free  if  they  want  to  use  and  even 
distribute  it  with  their  software.  In  return,  the  Navy 
hopes  to  have  available  many  more  software  tools 
with  the  innate  ability  to  extract  and  save  ship  data  to 
LEAPS  files.  This  year,  we  will  be  making  LEAPS 
even  more  accessible  by  creating  a  web-based 
community  of  developers,  where  questions  and 
examples  can  be  exchanged,  and  LEAPS  software 
and  documentation  downloaded.  In  addition,  we 
continue  to  expand  the  user  community  of  LEAPS 
through  navy  sponsored  software  development, 
where  use  of  LEAPS  is  made  contractual. 

PROVIDING  INFORMATION  TO  “THE 
OUTSIDE” 

Digital  product  models  have  the  ability  to  provide 
much  more  information  about  a  ship  than  paper 
drawings.  Information  on  design  intent,  engineering 
analyses,  and  inter-relation  of  systems  can  all  be 
presented  together,  but  as  a  technology  the  Navy  is 
still  learning  to  use  it  effectively.  The  issue,  as  we 
have  learned,  is  that  digital  data  formats  come  and 
go,  and  the  lifetime  of  a  CAD  system  is  often  shorter 
than  the  lifetime  of  a  class  of  ship.  Whereas,  storing 
paper  drawings  amounts  to  a  fairly  trivial  task, 
storing  digital  data  has  issues  with  computer  systems, 
operating  systems,  and  software  systems  that  are  all 
constantly  changing  and  evolving.  LEAPS  provides 
the  opportunity  for  the  Navy  to  be  stewards  of  their 


own  digital  data.  Rather  than  relying  on  the 
constantly  changing  tide  of  the  commercial  sector,  by 
defining  and  maintaining  the  LEAPS  standard,  the 
Navy  can  ensure  that  its  own  digital  data  stands  the 
test  of  time.  The  optimal  solution  is  a  neutral  file 
format  that  is  not  only  product  model  agnostic,  but 
transcends  all  phases  of  the  ships  lifecycle.  The 
reality  is  that  a  compelling  case  can  be  made  for 
archiving  the  native  data  along  with  one  or  more 
neutral  representations.  The  key  lies  in  having  a 
thorough  understanding  of  the  context  in  which  each 
format  has  the  advantage  and  the  pedigree  of  the 
infonnation  while  maintaining  strict  configuration 
control.  (Rakow,  et.  al.  2009)  Surely  maintaining 
LEAPS  as  a  standard  for  ship  design  data  must  be 
recognized  as  a  Navy  core  capability. 

One  of  the  major  technical  hurdles  will  be  the 
method  for  providing  this  information  to  prospective 
bidders.  From  the  perspective  of  the  Navy,  the  easiest 
path  would  be  to  provide  access  to  the  LEAPS 
repository  on  a  Navy  controlled  Integrated  Product 
Data  Environment.  Another  option  worthy  of 
exploration  is  to  provide  that  information  in  a 
standards  based  neutral  format.  At  this  time  the 
leading  candidate  for  a  neutral  approach  makes  use  of 
the  Standard  for  the  Exchange  of  Product  Model  Data 
(STEP).  Although  this  may  be  the  major  milestone 
that  would  require  digital  data  to  be  provided  by  the 
Navy,  it  is  not  the  only  time.  The  exchange  of  digital 
data  is  something  that  will  be  performed  in  a  near 
continuous  fashion  to  support  collaboration  during  a 
lifecycle  phase. 
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OBTAINING  INFORMATION  FROM  "THE 
OUTSIDE" 

Data  exchange  is  required  in  both  directions: 
especially  to  support  a  collaborative  effort.  During 
the  Preliminary  and  Contract  Design  phases,  there  is 
a  high  probability  that  information  will  be  required 
that  has  been  developed  outside  of  the  NAVSEA 
design  tools  environment.  Not  only  may  it  be  useful 
to  obtain  data  that  may  have  been  developed  by 
shipbuilders,  created  using  their  production  oriented 
tools,  but  from  a  myriad  of  other  sources  as  well. 
These  data  sources  may  include  equipment  suppliers, 
weapons  system  integrators,  and  as  we  migrate  to  an 
“open  architecture,”  the  pool  of  qualified  suppliers 
will  expand  significantly.  In  recognition  of  this 
environment,  NAVSEA  and  the  commercial 
shipbuilders  through  the  National  Shipbuilding 
Research  Program  are  working  to  identify  the 
minimum  set  of  information  that  needed  to  define  a 
ship  and  ships  systems.  This  Ship  Common 
Information  Model  (NSRP  2008)  is  a 
multidisciplinary  view  of  product  model  data  and 
transcends  life  cycle  phases  as  shown  in  figure  4.  It  is 
envisioned  that  this  view  will  be  developed  in 
collaboration  by  NAVSEA  04,  NAVSEA  05,  the 
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Figure  4  -  Ship  Common  Information  Model 


shipbuilders,  and  suppliers  of  design  tools  and 
Product  Data  Management  tools.  The  owner  of  a 


specific  piece  of  the  Ship  Common  Information 
Model  may  have  their  own  requirements  but  the 
content  will  be  balanced  since  the  stakeholders  span 
the  entire  ship  lifecycle. 

The  data  obtained  from  the  outside  concentrates 
on  the  as-designed  arrangement.  Typically,  NAVSEA 
would  like  to  obtain  the  geometry  and  associated  non 
graphical  data  in  suitable  detail  and  format  to  enable 
independent  analysis  to  validate  that  the  design  meets 
the  requirements.  This  means,  in  addition  to  the  as- 
designed  arrangement,  NAVSEA  will  look  to  the 
shipbuilder  to  provide  design  data  such  as  the  (a) 
molded  forms  suitable  for  defining  a  general 
arrangement,  (b)  scantling  level  of  detail  of  structure 
to  support  structural  (and  other  types  of)  analysis,  (c) 
functional  distributed  systems  model  (i.e.  path, 
components,  and  connections),  (e)  compartmentation, 
including  accesses,  opening,  and  tightness,  and  (f) 
some  fundamental  equipment  properties  (i.e.  weights, 
centers,  electrical  loads)  .  The  availability  of  this  data 
is  a  key  element  in  enabling  NAVSEA  technical 
warrant  holders  and  engineers  to  operate  within  the 
NAVSEA  05  tools  environment,  in  accordance  with 
VADM  Sullivan’s  vision  as  stated  in  the  2008  memo 
(ref:  Ser  05D/047  dtd  4  Feb  2008).  It  will  also 
provide  accurate  data  of  value  to  the  NAVSEA  04 
community  as  they  prepare  to  provide  support  for 
ships  after  they  are  delivered  to  the  fleet. 

DETAILED  DESIGN 

As  a  ship  design  progresses,  the  responsibility  of 
“detailed  design”  is  handed  off  to  industry,  and  the 
types  of  models  used  for  the  design,  primarily  CAD 
and  manufacturing  models,  are  fundamentally 
different  than  the  physics-based  ship  performance 
models  used  within  the  Navy.  At  the  time  the  detailed 
design  contract  is  awarded,  the  physics  based  analysis 
to  ascertain  whether  the  ship  meets  its  requirements 
should  be  complete,  and  the  ship  design  configuration 
should  be  fixed.  A  crucial  challenge  will  be  the 
ability  to  translate  the  shipyard's  detailed  design  data 
back  into  a  digital  format  appropriate  for  meshing 
and  analyzing  the  performance  of  the  designs.  The 
lifetime  of  a  ship  class  from  the  time  the  lead  ship  is 
conceived  to  the  time  the  final  ship  is  retired  far 
exceeds  the  lifetime  of  any  commercial  ship  design  or 
CAD  tool,  and  yet  computer-based  analysis  is  needed 
throughout  the  ships'  life  for  refits,  upgrades,  or 


ASNE  2010 


Kassel,  Cooper,  Mackenna 


10 


damage  incidents.  It  is  crucial  as  well  that  the  Navy 
become  stewards  of  the  digital  ship  design  data  for 
their  assets.  These  are  two  more  reasons  why  the 
Navy  must  continue  to  not  only  build  and  maintain 
the  LEAPS  system,  but  enforce  its  use. 

The  Navy  does  not  do  detailed  design  of  ships,  but 
during  detailed  design  the  Navy  has  a  continued 
responsibility  to  be  a  smart  customer  by  a  continuous 
process  of  accepting  data  for  review  and  perfonnance 
analysis.  As  the  design  matures,  NAVSEA  does  not 
need  manufacturing  data,  but  does  need  geometry 
structure,  arrangements,  and  parts  catalog  data  for 
systems  and  payloads.  The  component  catalog  data 
that  is  captured  in  LEAPS  for  new  class  specific 
systems  will  then  be  available  for  future  preliminary 
designs,  and  can  be  easily  accessed  to  assess 
commonality  of  future  designs  with  those  of  the  past. 

THIS  IS  ONLY  THE  BEGINNING 

This  paper  discussed  the  emerging  tools, 
modeling,  and  product  data  integration  environment 
being  developed  to  support  early  stage  naval  ship 
design.  It  is  true  that  Naval  ship  design  was 
performed  well  before  any  of  the  advanced 
computational  capabilities  we  seek  today  were 
available,  but  with  NAVSEA  at  less  than  a  quarter  of 
the  size  it  was  in  the  eighties,  the  rising  cost  of  ships, 
and  the  increasing  complexity  of  technology,  we 
cannot  afford  to  not  have  the  most  powerful  tools 
available.  Unfortunately,  this  is  balanced  by  the 
current  budget  for  tool  development  also  standing  at 
about  a  quarter  of  what  it  was  in  the  eighties  (not 
adjusted  for  inflation).  So  the  challenge  grows 
tougher  as  we  continue  to  develop  tomorrow’s  ships 
with  yesterday’s  tools. 
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